1. Field of the Invention
The invention pertains generally to integrating modules of computer code for execution on a computing device. More specifically, the invention relates to containing each module within a sandbox and controlling during runtime the ability of each module to access services provided by other modules.
2. Description of the Related Art
Hotels often purchase in-room entertainment and control systems from one or more outside vendors. Typically, a primary vendor handles the overall system and deals directly with the hotel owners while subcontracting various sub-portions to secondary vendors who may or may not have direct contact with the hotel owners. For example, a primary vendor may provide high speed Internet access (HSIA) and video-on-demand (VOD) servers and in-room set-top boxes (STBs) while subcontracting a secondary vendor to design an electronic control system for controlling various aspects of the guest rooms. The primary vendor and secondary vendor may work together to integrate their portions of the system such as to allow a guest to utilize a single infrared remote control device and an in-room television to browse the Internet, watch television (TV) and movies, and operate the in-room air-conditioner, lights, windows, and curtains.
After the system goes live, hotel management often desire to further customize and enhance the system. For example, management may wish to include a new feature unique to the hotel to distinguish the hotel from other hotels. In this situation, management typically contacts the primary vendor of the entertainment system to request incorporation of a special request or to add one or more new functions. Often the requested functions are very specific to the particular hotel and would not be useful or desirable to incorporate at other hotels. In addition to making direct changes to the system, the primary vendor may need to contact one or more secondary vendors if the requested feature involves interfacing with a secondary vendor's portion of the system.
It is inconvenient for hotel management to have to make these feature requests and to be limited to dealing only with the primary vendor. It would be beneficial if hotel management could simply make the changes to the system themselves such as by allowing a technical consultant or other third-party access to add a new feature to the installed entertainment system. It is likewise a financial and time burden on the primary and secondary vendors to handle these one-off feature requests for different hotels.
However, allowing the hotel or a third-party vendor to directly modify or add new features could cause stability problems since third-parties may not understand the system as whole. For example, in order to add a function to an in-room STB, a JavaScript program that controls the functions of the STB may need to be modified. Executing third-party JavaScript code on the in-room STB is risky both in terms of stability and security. Bugs may be inadvertently (or deliberately) introduced, and a malfunctioning third-party script has the potential to crash an in-room STB or interfere with the rest of the system. Security of guest data, hotel data, and media content is also a concern because each script running on the STB has unlimited access to the network and other valuable data within the STB. Content providers such as Hollywood studios have strict rules regarding encryption keys and content protection, and the primary system vendor must protect media assets such as pay-per-view and VOD content at all times. Giving untrusted third-party vendor code unlimited access to all functions of the STB is unacceptable under these rules.
Sandboxing is a well-known computer security technique utilized to isolate running computer programs from each other. Although JavaScript is a very insecure programming language, it is possible to “sandbox” a particular script by limiting the instructions and commands executable by the script according to the object-capability model. Generally speaking there are two approaches to using this capability-based security model to perform sandboxing on JavaScript: verification and translation.
The verification approach involves automatically checking before execution that a script is written entirely using a limited subset of the JavaScript language including only “safe” commands and language features that ensure the script is sandboxed. The original script is not changed at all during the verification process so verified scripts run at their native speed and with exactly their intended behavior. Only scripts that first pass the verification process are ensured to be isolated within their own sandbox and are allowed to be run. Scripts including one or more unsafe commands that could be used to act on or modify any information outside the sandbox fail the verification and cannot be run. ADsafe™ is an example of a nondestructive JavaScript verification tool that can be utilized to verify that a script is sandboxed at any stage of the deployment pipeline or after delivery as part of compliance testing.
The translation approach involves automatically translating a potentially unsafe original script file into a translated script file, which utilizes only code and language features that can be guaranteed at runtime to stay within the confines of a given set of sandbox rules. The Google™ Caja project is an example of a source-to-source JavaScript translator for securing JavaScript-based web content using this type of translation approach. Caja provides a compiler called a “cajoler” that generates a “cajoled” web application from a fail-stop subset of JavaScript that includes almost the entire JavaScript language except for a few error-prone constructs. Caja further allows for a wide range of flexible security policies including allowing a containing page to grant authority for an embedded application to access a particular web service.
Although the above verification and translation approaches are both viable options for including active content from untrusted third-parties into regular web sites, neither is optimal in an embedded environment such when running scripts on a STB in a hotel entertainment system. Due to limiting each script to its own sandbox, the verification approach impedes sharing functionality and information between scripts provided by different vendors. In this way, the verification approach is useful for inserting standalone active content such as advertisements or independent features that are not closely integrated with the existing system; however, hotel management may wish to add a new script to provide a feature on the STB that requires close integration with data and/or services provided by code already existing on the STB. Caja allows granting and denying authority to web services by passing and denying access to objects; however, a downside is the significantly increased length of the cajoled (i.e., translated) web applications and the resulting computational power requirements by devices executing the cajoled scripts. Caja is designed for web browsers running on modern personal computers, which may be orders of magnitude faster than a STB or other in-room embedded device typical found in a hotel entertainment system. In addition to running slower, the translated script file may also have new bugs or unexpected behaviors introduced by the Caja translation process itself, which further complicates testing and quality assurance efforts.